Het conceptueel gegevensmodel

Het ontwikkelen van een conceptueel gegevensmodel

Daaronder verstaat men de activiteit waarbij men de informatiebehoeften van groepen van gebruikers in een organisatie op een natuurgetrouwe wijze modelleert zonder dat men rekening houdt met implementatiedetails of met beperkingen in de (database)software waaronder de implementatie later gebeurt.

Het conceptueel gegevensmodel is een geformaliseerd model die gegevens van het applicatiedomein voorstelt. Er bestaan verschillende modellen. Wij gebruiken het ER model.

1. Doel:
   dit ER-model wordt later naar een relationeel database model omgezet.
2. Wat?
   formalisme om een conceptueel gegevensmodel te bouwen
3. Oorsprong?
   Peter CHEN (1976)
4. Belang?
   1. combineert een werkelijkheidsgetrouwe afbeelding met een hoge graad van formalisering
   2. compromis tussen uitdrukkingsvermogen en verstaanbaarheid
5. Bouwstenen van het ER-model:
   1. entiteittypen
   2. attribuuttypen
   3. relationshiptypen
6. Grafische voorstelling?
   1. ER-model (ERM): entity relation) model
   2. ER-diagram (ERD): entity relation diagram

1. Uitbreidingen?
   1. Enhanced Entity Relationship-Model (EER-model)

Een ERM of ERD bestaat uit de volgende onderdelen:

1. entiteit: een entiteit kan worden gezien als een ding, een "tastbaar" iets dat deel uitmaakt van het datamodel. Voorbeelden hiervan zijn: een auto, een werknemer, een lied of een gebied.
2. verwantschap: een verwantschap geeft het verband weer tussen twee of meer entiteiten, zoals "een werknemer werkt in een fabriek"; "werkt in" is hier de verwantschap tussen de entiteiten werknemer en fabriek.
3. attribuut: een attribuut is een eigenschap van een entiteit of verwantschap. Zo heeft een werknemer (onder andere) een voornaam, een achternaam, een woonplaats en een sofinummer. Het attribuut dat wordt gebruikt als unieke aanduiding van de entiteit (de primaire sleutel), wordt onderstreept weergegeven.

Elk van deze zaken wordt in een ER diagram weergegeven met een bepaald symbool weergegeven. Een entiteittype wordt met een rechthoek weergegeven, een verwantschaptype met een ruit (verbonden met lijnen aan de betrokken entiteiten) en een attribuuttypes wordt als een ovaal weergegeven.

Het entiteitstype is de fundamentele bouwsteen voor het beschrijven van de structuur van gegevens met het Entity Data Model (EDM). In een conceptueel model vertegenwoordigt een entiteitstype de structuur van concepten op het hoogste niveau, zoals klanten of bestellingen. Een entiteitstype is een sjabloon voor instanties van het entiteitstype, entiteiten genomed. Het onderscheid tussen een entiteitstype en een entiteit wordt niet altijd consekwent gevolgd zoals in onderstaand diagram:

1. Entiteit
   1. Wat zijn entiteiten?
      1. Objecten waarover wij gegevens willen verzamelen
      2. Fysiek (klant, leverancier) of conceptueel (beroep, job)
      3. Een entiteit heeft kenmerken of eigenschappen (attributen)
         1. levnr, leveranciersnaam, leveranciersadres, …
      4. Onbekende waarden (null values)
         1. Type versus individueel voorkomen
         2. Classificatie versus instantiatie
      5. Entiteittype versus entiteit
      6. Entiteittype is een verzameling van entiteiten met gelijksoortige kenmerken (attributen)
      7. Attribuut versus attribuuttypen
   2. Verschillende soorten entiteittypen
      1. Gewoon entiteittype
      2. Zwak entiteittype (‘weak entity type’)
         1. entiteittype dat niet over (voldoende) eigen attribuuttypen beschikt om een sleutel te vinden
            • voorbeeld: datamodel van hotelketen
              • entiteittypen: hotel, kamer, ...
              • attribuuttypen:
                • hotel: hotelnaam, ...
                • kamer: kamernummer, prijs, ...
              • kamer is een zwak entiteittype
                • sleutel kamer: kamernummer, hotelnaam
         2. een zwak entiteittype is altijd bestaansafhankelijk
            • het omgekeerde gaat niet op: bestaanafhankelijkheid hoeft niet noodzakelijk het bestaan van een zwak entiteittype te impliceren.
2. Attributen
   1. Hier wordt ook een onderscheid gemaakt tussen attribuuttypen en attributen.
   2. Enkelvoudige en samengestelde attribuuttypen
      1. Enkelvoudig (atomic): bv. levnummer
      2. Samengesteld: bv. levadres
   3. Single-valued en multiple-valued attribuuttypen
      1. single-valued: bv. levnummer
      2. multi-valued: bv. levadres (onder de assumptie dat een leverancier tegelijk meerdere adressen kan hebben)
   4. Sleutelattribuuttypen
      1. verzameling van één of meer attribuuttypen waarvan de waarden toelaten om een entiteit op een unieke wijze te identificeren
      2. één: bv. leverancier (levnummer)
      3. meer: bv. vlucht (vluchtnummer, datum)
      4. Uniqueness constraint
3. Verwantschapstypes (relationship types)
   1. Een relationshiptype representeert een verzameling gelijksoortige verbanden tussen entiteiten
      1. een relationship is een individueel voorkomen van dergelijk verband
      2. een relationshiptype heeft een naam
         1. bv. het relationshiptype in_bestelling modelleert de verbanden tussen leveranciers en aankooporders
   2. Ook relationshiptypen kunnen over attribuuttypen beschikken
      1. Indien de waarden van sommige attributen bepaald worden door een samenstelling van entiteiten uit een relationship, treden er attribuuttypen op voor dat relationshiptype
         1. bv. het relationshiptype aankoopvoorwaarden: levtermijn
   3. Graad van een relationshiptype: het aantal entiteittypen dat gebruikt is bij het tot stand komen van het verband
      1. 1 -> unair relationshiptype
      2. 2 -> binair relationshiptype (bv. relationshiptype ‘in bestelling’)
      3. 3 -> ternair relationshiptype
   4. Associatie-typen (rollen) bepalen de zin waarin een verband moet worden opgevat
      1. bv. het verband (‘in bestelling’) tussen leveranciers en aankooporders kan zowel vanaf leverancier, als vanaf aankooporder beschouwd worden
      2. iedere rol heeft een naam
         1. bv. relationshiptype ‘in_bestelling’: rollen lev-ao en ao-lev
   5. Cardinaliteit van een rol: het aantal keren dat een entiteit in die rol kan of moet optreden
      1. minimale cardinaliteit: 0 of 1
         1. 0: als het in die rol niet is vereist dat elke entiteit met een andere entiteit is gekoppeld (partiële participatie), bv. lev-ao
         2. 1: iedere entiteit moet minstens éénmaal in die rol optreden (bestaansafhankelijkheid), bv. ao-lev
      2. maximale cardinaliteit: 1 of n
         1. 1: als het in een rol is vereist dat met een entiteit maximaal één ander entiteit mag zijn gekoppeld, bv. ao-lev
         2. n: als een entiteit, in een rol, met een onbepaald aantal entiteiten mag zijn gekoppeld, bv. lev-ao
      3. 4 mogelijke combinaties: 0..1, 0..n, 1..1, 1..n

Voorbeelden

1. UML ERD
   1. UML ERD Boeken

      

   2. UML ERD Mikmak

      

   3. UML ERD Fric-frac

      

   4. UML ERD Myaa

      

2. Gewoon ERD:

   

3. Myaa ERD: